6.04. Руководство пользователя по ГОСТ Р 59795 – 2021

В РАЗРАБОТКЕНЕ ДЛЯ НОВИЧКОВНЕ ОБЯЗАТЕЛЬНО

Руководителю Аналитику Техническому писателю

Руководство пользователя

ГОСТ

Основано на ГОСТ Р 59795 – 2021.

1. Введение: стандарт и его роль в техническом письме

1.1. О чём этот стандарт

ГОСТ Р 59795–2021 — национальный стандарт Российской Федерации, регламентирующий требования к содержанию документов, разрабатываемых при создании автоматизированных систем (АС). Он является прямым развитием и уточнением комплекса стандартов ГОСТ 34 (в частности — ГОСТ 34.201 и ГОСТ 34.602), дополняя их детализацией по структуре и содержанию каждого типа документа.

Стандарт введён в действие с 30 апреля 2022 г. и распространяется на АС всех видов деятельности:

научные исследования (НИР),
управление (АСУ),
проектирование (САПР),
производство (АСУ ТП),
а также на их комбинированные формы.

📌 Ключевая идея стандарта:
«Содержание каждого документа определяет разработчик в зависимости от объекта проектирования, но при этом — в рамках строго регламентированной базовой структуры» (п. 4.3).

Таким образом, ГОСТ Р 59795–2021 не предписывает «жёсткий шаблон», но задаёт:

обязательные разделы (должны присутствовать всегда),
рекомендованные элементы (включаются по усмотрению, если они необходимы для полноты описания),
порядок и логику изложения (обеспечивает единообразие и однозначность интерпретации).

1.2. Что такое «Руководство пользователя» в контексте стандарта

Руководство пользователя (РП) — один из ключевых эксплуатационных документов, предназначенный для:

персонала-пользователя, непосредственно взаимодействующего с системой,
администраторов и специалистов поддержки,
обучающихся (в образовательных или пилотных проектах).

Согласно п. 6.4 стандарта, РП — это документ, позволяющий пользователю:

понять назначение и границы применения системы,
подготовить систему к работе,
выполнять операции в штатном и аварийном режимах,
безопасно освоить функционал.

📌 Важно:
В отличие от инструкций по эксплуатации технических средств (п. 7.17) или технологических инструкций (п. 6.3),
Руководство пользователя фокусируется не на «железе» или отдельных операциях, а на средствах автоматизации как программно-функциональных компонентах, включая их взаимодействие с пользователем и средой.

1.3. Структура «Руководства пользователя» по ГОСТ Р 59795–2021 (п. 6.4)

Стандарт предписывает следующую базовую структуру (все разделы обязательны, их отсутствие считается нарушением):

№	Раздел	Краткое содержание (по ГОСТ)
1	Введение	Область применения средства, возможности, уровень подготовки пользователя, перечень сопутствующей документации.
2	Назначение и условия применения	Для каких функций/видов деятельности предназначено; условия (аппаратные, программные, кадровые, информационные).
3	Подготовка к работе	Состав носителя, порядок загрузки ПО и данных, проверка работоспособности.
4	Описание операций	Все выполняемые функции/задачи; описание операций технологического процесса обработки данных.
5	Аварийные ситуации	Действия при отказах, ошибках, несанкционированном доступе, прочих ЧС.
6	Рекомендации по освоению	Советы по обучению, контрольный пример, порядок его запуска и выполнения.

⚖️ Примечание по гибкости:
Согласно п. 4.2, допускается:

объединять разделы (если логика требует),

добавлять подразделы и приложения,

исключать подпункты — но только при условии, что это не ведёт к потере смысла или нарушению функциональной полноты.

Рекомендуется следовать иерархии подачи информации: от целей → к условиям → к действиям → к исключениям → к обучению.

2. Пошаговое руководство по составлению Руководства пользователя

Шаг 1. Подготовка и сбор исходных данных

Прежде чем писать РП, необходимо убедиться, что есть:

Техническое задание (ТЗ) на АС (по ГОСТ 34.602) — основной источник требований к функциям и ограничениям;
Описание программного обеспечения (п. 9.1) — для разделов «Подготовка к работе» и «Описание операций»;
Общее описание системы (п. 5.11) — для разделов «Введение» и «Назначение»;
Схемы функциональной структуры (п. 5.3), описание технологического процесса обработки данных (п. 6.5) — для описания операций;
Паспорт и Формуляр (пп. 5.8–5.9) — для информации о гарантиях и состоянии (в приложениях/дополнительно);
Программа и методика испытаний (п. 5.13) — особенно её раздел «Аварийные ситуации» и протоколы сбоев.

🔍 Лучшая практика:
Используйте матрицу трассировки требований (traceability matrix), сопоставляя каждый пункт РП с конкретным пунктом ТЗ или спецификацией функции — это гарантирует покрытие всех заявленных возможностей.

Шаг 2. Формирование структуры документа

Используйте следующий каркас (можно сохранить как шаблон в Confluence / Obsidian / Docusaurus):

# Руководство пользователя  
Системы «[Название]»  
Версия: [X.Y]  
Дата: [ГГГГ-ММ-ДД]  
Разработчик: [Организация]  

## 1. Введение  
### 1.1 Область применения  
### 1.2 Основные возможности  
### 1.3 Уровень подготовки пользователя  
### 1.4 Сопутствующая документация  

## 2. Назначение и условия применения  
### 2.1 Назначение  
### 2.2 Требования к техническим средствам  
### 2.3 Требования к программному обеспечению  
### 2.4 Требования к входной информации  
### 2.5 Требования к персоналу  

## 3. Подготовка к работе  
### 3.1 Состав поставки  
### 3.2 Установка и развёртывание  
### 3.3 Проверка работоспособности  

## 4. Описание операций  
### 4.1 Общая схема работы  
### 4.2 Запуск и инициализация  
### 4.3 Выполнение функций  
…  
### 4.n Завершение работы  

## 5. Аварийные ситуации  
### 5.1 Типовые сценарии отказов  
### 5.2 Восстановление после сбоев  
### 5.3 Защита от несанкционированного доступа  

## 6. Рекомендации по освоению  
### 6.1 Этапы обучения  
### 6.2 Контрольный пример  
### 6.3 Тестовые сценарии  

## Приложения  
- A. Скриншоты интерфейса  
- B. Примеры файлов входных/выходных данных  
- C. Коды ошибок и их расшифровка  

Шаг 3. Наполнение содержания по разделам

Рассмотрим подробно каждый обязательный раздел — что писать, в каком стиле, на что обращать внимание.

3.1. Введение

Подраздел	Что включать	Как оформлять
1.1 Область применения	Для каких функций, процессов, ролей предназначено. Указать, какие подсистемы охватывает данное РП (если АС модульная).	Конкретно, без «воды». Пример: «Документ применим к модулю "Планирование закупок" системы X и распространяется на пользователей ролей "Экономист", "Руководитель отдела закупок", "Администратор"».
1.2 Основные возможности	Краткий перечень ключевых функций (не более 7–10), сгруппированных по логике (ввод → обработка → анализ → экспорт).	Можно в виде маркированного списка. Избегать маркетинговых формулировок («революционный», «уникальный»).
1.3 Уровень подготовки пользователя	Требуемая квалификация: знание предметной области, навыки работы с ОС, базовые ИТ-навыки.	Пример: «Пользователь должен владеть базовыми навыками работы в Windows/Linux, иметь представление о процессе закупочной деятельности и знать термины: лот, поставщик, спецификация».
1.4 Сопутствующая документация	Перечень других документов, с которыми обязательно нужно ознакомиться перед использованием.	Таблица:

Документ	Обозначение	Назначение
Техническое задание	ТЗ-Х-001	Основные требования к функциям
Инструкция по установке	ИУ-Х-002	Подготовка ОС и СУБД
Описание форматов данных	ОФД-Х-003	Структура CSV/XSD для импорта

3.2. Назначение и условия применения (п. 6.4.3)

Этот раздел отвечает на ключевой вопрос:

Для кого и при каких условиях система действительно работает как заявлено?

Здесь не описывают интерфейс и не объясняют, как кликать кнопки — только рамки, в которых функционал становится валидным.

Подраздел	Что включать	Пример корректной формулировки	Распространённая ошибка
2.1 Назначение	- Какие функции/процессы автоматизирует система? - Какие объекты охватывает? (например, «процесс закупки в рамках одного филиала», а не «вся логистика компании») - Какие задачи решает (в терминах бизнес-показателей: сокращение сроков, повышение точности и т.д.)	«Система X предназначена для автоматизации процесса подготовки и согласования технических заданий на разработку внутренних ИТ-проектов в рамках единого центра компетенций. Обеспечивает контроль жизненного цикла ТЗ от инициации до утверждения и передачи в разработку».	«Универсальный инструмент для управления проектами» — слишком расплывчато.
2.2 Требования к техническим средствам	- Минимальная/рекомендованная конфигурация сервера и клиентских рабочих мест - Требования к сетевому взаимодействию (протоколы, порты, задержки) - Совместимость с периферийным оборудованием (если есть: сканеры, принтеры, терминалы)	«Сервер: не менее 4 ядер, 16 ГБ ОЗУ, 100 ГБ SSD, CentOS 7.9 или Ubuntu 20.04 LTS. Веб-клиент: браузер Chrome `≥`100, Firefox `≥`102, Edge `≥`100. Поддержка печати на принтерах с драйверами PCL5/6».	«Работает на современном ПК» — неопределённо.
2.3 Требования к программному обеспечению	- Версии ОС, СУБД, промежуточного ПО (Java, .NET, Node.js) - Необходимые библиотеки, зависимости (с версиями) - Требования к среде исполнения (Docker `≥`20.10, Kubernetes `≥`1.24)	«СУБД: PostgreSQL 13.6, расширение pg_trgm. Backend: .NET 6.0.401, ASP.NET Core. Frontend: Node.js 18.16, React 18.2. Сборка контейнеров: Dockerfile на основе образа mcr.microsoft.com/dotnet/aspnet:6.0».	«Требуется SQL-сервер» — без указания СУБД и версии.
2.4 Требования к входной информации	- Форматы (XML/JSON/CSV/XLSX), схемы (XSD, JSON Schema) - Обязательные поля, допустимые диапазоны значений - Источники данных (API других систем, файлы, ручной ввод)	«Импорт поставщиков: CSV-файл, кодировка UTF-8, разделитель `;`. Обязательные поля: `inn` (строго 10 или 12 цифр), `name` (не пусто, `≤`255 символов), `status ∈ {active, blocked}`. Доступ к API ФНС (v2) должен быть настроен отдельно».	«Данные загружаются из Excel» — без структуры и валидации.
2.5 Требования к персоналу	- Должностные роли + необходимые компетенции - Сертификаты (если требуются: по ИБ, по СУБД и т.д.) - Требования к знанию предметной области	«Роль “Технический аналитик”: знание методологии проектирования ТЗ по ГОСТ 34.602, опыт работы с BPMN 2.0, базовое понимание REST API. Не требуется сертификация, но рекомендуется прохождение внутреннего курса “Анализ требований в ИТ”».	«Ответственный сотрудник» — без уточнения роли и компетенций.

📌 Примечание: Все требования, сформулированные здесь, должны иметь прямую ссылку на пункт ТЗ. Это критично для аудита и приёмо-сдаточных испытаний.

3. Подготовка к работе

3.1. Состав поставки

В поставку входят следующие артефакты:

systemx-core-2.3.1.zip — основной архив, содержащий исполняемые модули и библиотеки;
db-schema-2025.sql — скрипт инициализации структуры базы данных;
init-data.sql — скрипт загрузки начальных (справочных) данных;
docker-compose.yml — файл развёртывания в среде Docker Compose;
каталог certs/ — сертификаты TLS (включая корневой и промежуточный);
каталог docs/ — эксплуатационная документация в форматах PDF и HTML.

Для обеспечения целостности поставки все бинарные файлы снабжены контрольными суммами SHA-256. Перед установкой рекомендуется проверить соответствие хешей:

systemx-core-2.3.1.zip: 6a7b3c1d8e2f5a0b9c4d6e8f2a1b3c5d7e9f0a2b4c6d8e0f2a4b6c8d0e2f4a6b
systemx-web.war: a1b2c3d4e5f6a7b8c9d0e1f2a3b4c5d6e7f8a9b0c1d2e3f4a5b6c7d8e9f0a1b2
init-data.sql: d4e5f6a7b8c9d0e1f2a3b4c5d6e7f8a9b0c1d2e3f4a5b6c7d8e9f0a1b2c3d4e5

Проверка выполняется стандартными средствами ОС, например:

sha256sum systemx-core-2.3.1.zip
# Ожидаемый вывод:
# 6a7b3c1d8e2f5a0b9c4d6e8f2a1b3c5d7e9f0a2b4c6d8e0f2a4b6c8d0e2f4a6b  systemx-core-2.3.1.zip

3.2. Установка и развёртывание

Внимание: Все действия выполняются от имени пользователя с правами на запись в целевую директорию и запуск процессов. Использование sudo допускается только для установки системных зависимостей (например, Docker), но не для запуска приложения.

Распаковка архива
Поместите systemx-core-2.3.1.zip в целевую директорию (например, /opt/systemx) и выполните:
```
unzip systemx-core-2.3.1.zip -d /opt/systemx
```
После распаковки структура каталога должна содержать подкаталоги:
bin/, conf/, lib/, logs/, web/.

Инициализация базы данных
Предполагается, что СУБД PostgreSQL 13.6 или выше уже установлена и запущена.

# Создание БД и пользователя
psql -U postgres -c "CREATE DATABASE systemx;"
psql -U postgres -c "CREATE USER sysx WITH PASSWORD 'initial-pass-2025';"
psql -U postgres -c "GRANT ALL PRIVILEGES ON DATABASE systemx TO sysx;"

# Применение схемы и начальных данных
psql -U sysx -d systemx -f /opt/systemx/db-schema-2025.sql
psql -U sysx -d systemx -f /opt/systemx/init-data.sql

Настройка окружения
Скопируйте шаблон конфигурации и отредактируйте его:
```
cp /opt/systemx/conf/.env.example /opt/systemx/conf/.env
```
В файле .env обязательно задайте следующие параметры:
- DB_HOST — хост СУБД (например, localhost или IP-адрес сервера);
- DB_PORT — порт СУБД (по умолчанию 5432);
- DB_NAME=systemx — имя базы данных;
- DB_USER=sysx, DB_PASSWORD=initial-pass-2025 — учётные данные;
- JWT_SECRET — строка длиной не менее 32 символов (должна быть заменена перед вводом в эксплуатацию);
- MAX_UPLOAD_SIZE=52428800 — максимальный размер загружаемого файла в байтах (по умолчанию — 50 МБ).
Запуск приложения
Запуск осуществляется через скрипт startup.sh:
```
chmod +x /opt/systemx/bin/startup.sh
/opt/systemx/bin/startup.sh
```
При первом запуске система автоматически сгенерирует:
- ключи шифрования для сессий,
- начальный профиль администратора (admin@example.com, временный пароль SysX!2025).
⚠️ Требование безопасности:
Вход под учётной записью admin@example.com обязательно должен сопровождаться сменой пароля и пересозданием JWT_SECRET. Использование временных учётных данных в эксплуатации запрещено.

3.3. Проверка работоспособности

Корректность развёртывания подтверждается следующими признаками:

В лог-файле /opt/systemx/logs/systemx.log отсутствуют записи уровня ERROR или FATAL;
Сервис API отвечает на запрос /api/v1/health со статусом HTTP 200 и телом:
```
{
  "status": "UP",
  "db": "OK",
  "version": "2.3.1",
  "uptime": "125s"
}
```
Веб-интерфейс доступен по адресу https://<host>:8443 и отображает форму входа с логотипом «Система X»;
Доступен встроенный smoke-тест — выполните:
```
curl -k -s https://localhost:8443/api/v1/health | jq -r '.status'
# Ожидаемый вывод: UP
```
При наличии ошибок в ответе (например, "db":"DOWN"), проверьте:
- доступность хоста и порта СУБД;
- корректность параметров в .env;
- права пользователя sysx в PostgreSQL.

После подтверждения работоспособности рекомендуется выполнить контрольный пример (см. раздел 6).

3.4. Описание операций (п. 6.4.5–6.4.6)

Это ядро Руководства пользователя — здесь описывают как система решает задачи пользователя, а не как устроены её внутренние модули.

Принципы написания:

Ориентация на сценарии, а не на экраны: «Подать заявку на согласование ТЗ», а не «Форма “Новое ТЗ”».
Стандартная структура описания операции (обязательно по п. 6.4.6):

Элемент	Что писать	Пример
Наименование	Глагол + объект: кратко, по делу	«Согласовать техническое задание»
Условия выполнения	Предусловия: роль, статус объекта, наличие прав	«Пользователь имеет роль “Утверждающий”, ТЗ находится в статусе “На согласовании”, срок согласования не истёк»
Подготовительные действия	Что сделать до запуска (открыть список, выбрать объект)	«Открыть раздел “Мои согласования” → найти ТЗ по номеру или фильтру “Срок `≤` 3 дня”»
Основные действия	Пошагово, в порядке выполнения. Можно — с UI-описанием	1. Нажмите кнопку “Открыть” (иконка 📄). 2. Пролистайте до блока “Согласующие”. 3. В строке “Утверждающий” нажмите ✓ Принять или ✗ Отклонить.
Заключительные действия	Что происходит после: уведомления, переходы, артефакты	«Система обновляет статус ТЗ на “Утверждено” или “Отклонено”, отправляет уведомление инициатору, блокирует редактирование полей, кроме комментария»
Ресурсы	Время, сетевой трафик, лицензии, лимиты	«Операция занимает `<`2 с. Требуется 1 лицензия модуля “Согласование”. Лимит: не более 100 согласований/день на пользователя»

🔎 Рекомендация: Используйте таблицу операций в начале раздела как оглавление:

№	Операция	Роль	Среднее время	Частота
3.1	Создать черновик ТЗ	Аналитик	3–5 мин	Высокая
3.2	Согласовать ТЗ	Утверждающий	`<`30 с	Высокая
3.3	Экспортировать ТЗ в PDF	Любой	5–10 с	Средняя

3.5. Аварийные ситуации (п. 6.4.7)

Не просто «что делать при ошибках», а управление инцидентами с привязкой к процессу.

Сценарий	Действия пользователей	Действия администратора	Документирование
Долгий отказ сервера (`>`5 мин)	1. Проверить `/health`. 2. Сохранить черновики локально (если есть). 3. Сообщить в службу поддержки (канал: `#support-systemx`).	1. Проверить логи (`/var/log/systemx/error.log`). 2. Перезапустить контейнер: `docker restart sysx-app`. 3. При повторении → открыть инцидент в Jira (проект `SYSX-OPS`).	Запись в журнал аварий (раздел Формуляра): дата, код ошибки, длительность, причина (если установлена), ФИО ответственного.
Ошибка валидации при импорте CSV	1. Скачать отчёт об ошибках (кнопка “Скачать лог”). 2. Исправить строки с кодами `E101`, `E205`. 3. Повторить загрузку.	При массовых ошибках (`>`10% строк): проверить шаблон CSV на портале; обновить справочник кодов ИНН из ФНС.	В ПМИ (п. 5.13.4) предусмотрена проверка «Качество входных данных» — использовать её при инцидентах.
Попытка несанкционированного доступа	1. Немедленно разлогиниться (кнопка Выход). 2. Не использовать пароль повторно. 3. Уведомить ИБ-службу.	1. Заблокировать IP в WAF. 2. Отозвать refresh-токены. 3. Проверить аудит-логи (`SELECT * FROM audit WHERE event_type = 'login_attempt' AND result = 'fail'`).	Обязательно фиксируется в «Журнале безопасности» (по требованиям ФСТЭК).

🛡️ Совет: Включите таблицу кодов ошибок в приложение С — это сокращает время реакции в 2–3 раза.

3.6. Рекомендации по освоению (п. 6.4.8)

Этот раздел превращает РП из «технической справки» в обучающий ресурс.

Что обязательно включить:

Этапы обучения (лестница компетенций):
- Уровень 1: Наблюдатель (только просмотр)
- Уровень 2: Исполнитель (ввод, экспорт)
- Уровень 3: Координатор (согласование, корректировка)
- Уровень 4: Администратор (настройка, интеграция)
Контрольный пример — полный сквозной сценарий, от старта до финала:
- Имя: «Разработка ТЗ на модуль отчётов для ELMA365»
- Исходные данные: приложены (PDF ТЗ, CSV поставщиков, XSD схема)
- Последовательность:
  Создание → Заполнение разделов → Привязка к проекту → Согласование → Утверждение → Экспорт в PDF
Тестовые сценарии — задания для самопроверки:

📝 Задание 1:
В контрольном примере измените статус поставщика с active на blocked и проверьте, отобразится ли предупреждение при выборе в форме «Исполнитель».
Ожидаемый результат: значок ⚠️, текст «Поставщик заблокирован», кнопка «Выбрать» неактивна.

🚫 Часть 3: Типичные ошибки и методы их предотвращения

При анализе реальных РП, разработанных в российских гос- и коммерческих проектах, можно выделить пять классов ошибок, систематически нарушающих требования ГОСТ Р 59795–2021 и снижающих эксплуатационную ценность документа.

Ниже — по каждому классу:

формулировка ошибки,
последствия (с точки зрения пользователя и эксплуатации),
причина (часто методологическая, а не техническая),
методы предотвращения (включая приёмы технического письма и контрольные процедуры).

3.1. Ошибка «Технический справочник вместо Руководства»

Суть:

Автор описывает не операции пользователя, а архитектуру, API, классы и таблицы БД. Получается гибрид РП + Спецификации ПО + Описания БД.

Пример нарушения:

«Сервис TaskService реализует интерфейс ITaskExecution, метод ExecuteAsync() вызывает DbContext.SaveChanges(). Таблица tasks содержит поля: id (UUID), status (int), assignee_id (FK → users.id)».

❌ Такой фрагмент нарушает п. 6.4.5 — описание должно касаться операций технологического процесса, а не внутренностей реализации.

Последствия:

пользователь не понимает, что делать и в какой последовательности;
администратор не может быстро локализовать проблему без дополнительного чтения кода;
в случае аудита — документ признаётся несоответствующим ГОСТ.

Причина:

Автор — разработчик, привыкший к «внутренней» логике системы.
Отсутствие чёткого разделения между разработческими и эксплуатационными документами (п. 4.1 ГОСТ).

Как избежать:

✅ Принцип «пользовательского сценария»:
Каждый подраздел должен начинаться с глагола действия в повелительном наклонении:
→ «Создать заявку», «Проверить статус согласования», «Восстановить резервную копию».

✅ Правило «чёрного ящика»:
Описывайте только то, что видит/делает пользователь:

входные данные (форма, файл, API-запрос — но не DTO);
действия (нажать, выбрать, отправить);
результат (уведомление, изменение статуса, файл отчёта — но не HTTP-код).

✅ Контрольный вопрос при редактировании:
«Сможет ли пользователь выполнить эту операцию, не зная, как устроена БД и какой фреймворк используется?»
Если нет — переписывайте.

3.2. Ошибка «Недетерминированность условий выполнения»

Суть:

В описании операций отсутствуют чёткие предусловия, и пользователь пытается выполнить действие в невозможном состоянии.

Пример:

«Для согласования ТЗ нажмите кнопку “Утвердить”»
— но не сказано:

когда кнопка доступна (статус = «На согласовании»?),
какая роль требуется («Утверждающий»?),
не истёк ли срок («не позднее 5 раб. дней с момента создания»?).

Это прямое нарушение п. 6.4.6 (второй пункт): «условия, при соблюдении которых возможно выполнение операции».

Последствия:

рост обращений в службу поддержки;
возникновение ошибок вида «Кнопка неактивна», «Нет прав» — без объяснения причины;
формирование у пользователя ощущения «капризности» системы.

Причина:

Проектировщики считают условия «очевидными»;
ТЗ не содержит явных бизнес-правил (например, «согласование отклоняется автоматически по истечении срока»);
Отсутствие формализации workflow (BPMN, state machine).

Как избежать:

✅ Формализуйте условия с помощью шаблона:

Условие	Значение в системе	Как проверить
Роль пользователя	`role == "approver"`	В профиле — «Утверждающий»
Статус ТЗ	`status == "review"`	В карточке — статус «На согласовании»
Срок действия	`created_at + 5d > now()`	Дата создания + 5 раб. дней ≥ текущая

✅ Используйте таблицы валидации в РП (можно в приложении или отдельном разделе «Правила системы»).
✅ Согласуйте условия с ТЗ и схемой функциональной структуры (п. 5.3). Если в них нет — верните на доработку.

3.3. Ошибка «Аварийные ситуации — как приложение, а не как раздел»

Суть:

Раздел «Аварийные ситуации» либо отсутствует, либо сведён к формулировке «Обратитесь в техподдержку».

Нарушает п. 6.4.7, который требует конкретных действий в 4 типах ситуаций:

отказ технических средств,
повреждение/ошибка в данных,
несанкционированный доступ,
прочие аварии.

Пример слабого варианта:

«При возникновении ошибок свяжитесь со службой поддержки по телефону 555-55-55».

❌ Это не инструкция, а перекладывание ответственности.

Последствия:

увеличение времени простоя системы;
рост нагрузки на поддержку;
невозможность восстановления без участия администратора — даже при мелких сбоях (например, сбой сессии).

Причина:

Отсутствие тест-кейсов на аварийные сценарии в ПМИ (п. 5.13);
Страх «дать волю пользователю» — опасение некорректных действий;
Отождествление РП с «гарантийным документом», а не с инструментом управления рисками.

Как избежать:

✅ Разработайте матрицу аварийных сценариев на этапе проектирования. Пример фрагмента:

Тип аварии	Признак	Действие пользователя	Действие администратора
Сбой сессии	Ошибка `ERR_SESSION_EXPIRED`	1. Сохранить черновик вручную. 2. Перезайти.	Проверить `SESSION_TIMEOUT`, логи аутентификации.
Ошибка импорта	Сообщение «Строка 42: неверный ИНН»	1. Скачать лог. 2. Исправить CSV. 3. Повторить.	Обновить справочник ИНН из ФНС API.

✅ Внедрите «аварийные кнопки» в UI — и опишите их в РП:
→ «Кнопка Автовосстановление сессии в правом верхнем углу (значок 🔄)».

✅ Интегрируйте РП с системой мониторинга:
Если используется Sentry, Prometheus, ELK — добавьте в РП ссылки-шаблоны:

Логи по ТЗ-12345:  
https://logs.example.com/app/systemx?q=task_id:12345&level:error

3.4. Ошибка «Контрольный пример — как абстракция»

Суть:

Раздел «Рекомендации по освоению» (п. 6.4.8) содержит общие советы («начните с простых операций»), но отсутствует конкретный контролируемый сценарий — итоговый результат нельзя проверить объективно.

Последствия:

новички не могут убедиться, что освоили систему правильно;
обучение превращается в «тыкание по интерфейсу»;
отсутствие критериев при приёмке на работу («знает систему» ≠ «прошёл контрольный пример»).

Причина:

Нет единого контрольного примера в ТЗ и в ПМИ;
Разработчики не тестируют «сценарии первого запуска»;
Педагогическая неграмотность составителя.

Как избежать:

✅ Требуйте контрольный пример в ТЗ (п. 4.2 ГОСТ 34.602 допускает дополнения).
✅ Соблюдайте структуру контрольного примера:

Элемент	Требования
Имя	Уникальное, отражающее суть: `Сценарий_ТЗ_Создание_и_Согласование_v1`
Исходные данные	Фиксированный набор: CSV, XML, JSON — с контрольными суммами.
Ожидаемые промежуточные состояния	После шага 3 — статус = «Черновик»; после шаг 7 — уведомление отправлено.
Ожидаемый финал	PDF-файл `ТЗ-TEST-2025.pdf`, хеш SHA-256: `a1b2c3...`
Критерий успеха	Все 8 шагов завершены без ошибок; итоговый файл совпадает по хешу.

✅ Используйте «обучающий режим» в системе (если реализован):
→ РП должно описывать его включение:
«Режим обучения: профиль → Настройки → ✅ “Тренировочный режим” → Перезагрузка».

3.5. Ошибка «Неадаптированность под роли»

Суть:

Одно РП на всех — аналитика, руководителя, администратора.
Но по п. 6.4.2 требуется указывать «уровень подготовки пользователя», а по п. 5.2.4 — «функции и роли персонала».

Пример:

Раздел «Подготовка к работе» описывает развёртывание Docker-кластера, но не содержит упрощённую инструкцию для пользователя, которому нужно только ввести данные.

Последствия:

пользователи пропускают важные разделы, ориентированные на других ролей;
«информационный шум» снижает доверие к документу;
необходимость писать отдельные «инструкции по ролям» — дублирование.

Как избежать:

✅ Применяйте модульную структуру РП (допускается по п. 4.2 ГОСТ Р 59795–2021):

Руководство_пользователя_Системы_X.pdf  
├── Общая часть (введение, назначение, аварии)  
├── Модуль_Аналитик.pdf  
├── Модуль_Утверждающий.pdf  
└── Модуль_Админ.pdf  

✅ Используйте теги ролей в заголовках:

### 4.3.2 Согласовать ТЗ  
*Роль: «Утверждающий», «Руководитель»*  

✅ Добавьте «карту знаний» в начало РП — таблицу «Что читать, если вы…»:

Ваша роль	Обязательные разделы	Опционально
Аналитик	1, 2, 4.1–4.4, 6.2	3.2, 5.2
Утверждающий	1, 2, 4.5–4.7, 5.1	3, 6
Администратор	2.2–2.3, 3, 5, 6.3	4.1–4.4

📘 Руководство пользователя

Система «ТехноДок»

Модуль «Управление техническими заданиями»
Версия: 2.1
Дата: 2025-11-11
Разработчик: ООО «ИТ-Стандарт»

1. Введение

1.1 Область применения

Настоящее Руководство пользователя распространяется на модуль «Управление техническими заданиями» системы «ТехноДок» и предназначено для сотрудников, участвующих в жизненном цикле технических заданий (ТЗ) на разработку внутренних ИТ-проектов:

инициаторов ТЗ (роль «Аналитик»),
технических экспертов (роль «Эксперт»),
согласующих (роль «Руководитель подразделения»),
утверждающих (роль «IT-директор»),
администраторов модуля (роль «Администратор системы»).

Документ не охватывает модули «Управление задачами», «Контроль исполнения», «Отчёты» — их описание приведено в отдельных руководствах.

1.2 Основные возможности модуля

Модуль обеспечивает:

создание и редактирование черновиков ТЗ в структурированном формате;
привязку ТЗ к бизнес-процессу, проекту, бюджету;
многоуровневое согласование (до 3 уровней) с автоматическим расчётом сроков;
версионирование ТЗ и контроль изменений;
экспорт ТЗ в PDF, DOCX, XML (в соответствии с ГОСТ 34.602);
интеграцию с ELMA365 и Jira (через API v2).

1.3 Уровень подготовки пользователя

Пользователь должен обладать следующими компетенциями:

знание основ проектирования ИТ-решений;
понимание структуры ТЗ по ГОСТ 34.602 (разделы 2–8);
базовые навыки работы в веб-интерфейсе (браузер Chrome ≥110 или аналог);
право доступа к внутреннему порталу компании (единая аутентификация SSO через Keycloak).

Для ролей «Администратор системы» дополнительно требуются:

знания PostgreSQL 13+,
опыт работы с Docker/Compose,
понимание принципов RBAC.

1.4 Сопутствующая документация

Перед работой с модулем необходимо ознакомиться со следующими документами:

Документ	Обозначение	Назначение
Техническое задание на систему «ТехноДок»	ТЗ-ТД-001-2025	Основные требования к функциям
Описание API модуля «ТЗ»	API-TZ-DOC-2.1	Для интеграций и автоматизации
Инструкция по установке	ИУ-ТД-102	Для администраторов
Политика информационной безопасности	ПИБ-2025	Обязательные требования к работе с данными

2. Назначение и условия применения

2.1 Назначение

Модуль предназначен для автоматизации процесса формирования, согласования и утверждения технических заданий на разработку программных продуктов, включая:

документальные требования (функциональные, нефункциональные, интерфейсные),
бюджетные и временные оценки,
обоснование необходимости разработки.

Модуль не предназначен для:

замены экспертной оценки архитектуры (выполняется вручную),
управления сметами после утверждения ТЗ (передача в модуль «Бюджет»),
работы с ТЗ, не соответствующими шаблону ГОСТ 34.602.

2.2 Требования к техническим средствам

Компонент	Минимум	Рекомендуемо
Сервер приложения	4 ядра, 8 ГБ ОЗУ, 50 ГБ SSD	8 ядер, 16 ГБ ОЗУ, 200 ГБ SSD NVMe
СУБД	PostgreSQL 13.6	PostgreSQL 14.5
Веб-клиент	Chrome 110+, Firefox 102+, Edge 110+	Chrome 120+
Сеть	Пинг ≤100 мс до сервера	Пинг ≤20 мс, шифрование TLS 1.3

2.3 Требования к программному обеспечению

ОС сервера: Ubuntu 20.04 LTS или CentOS 7.9
Docker Engine ≥ 20.10
Docker Compose ≥ 2.10
Java Runtime Environment ≥ 17 (для backend-сервисов)
Node.js ≥ 18.16 (для фронтенд-сборки, при развёртывании из исходников)

2.4 Требования к входной информации

Поддерживаются следующие форматы входных данных:

Импорт ТЗ: XML (в соответствии со схемой tz-gost34-2.1.xsd, см. приложение А),
Справочники поставщиков: CSV, кодировка UTF-8, разделитель ;, поля: inn, name, status, contact_email,

Интеграционные события: JSON по REST/POST в формате:

{
  "event": "tz.submitted",
  "payload": { "tz_id": "TZ-2025-0472", "initiator_id": "u-12345" }
}

2.5 Требования к персоналу

Роль	Обязательные компетенции	Необходимые сертификаты
Аналитик	Знание ГОСТ 34.602, опыт описания требований	Нет
Эксперт	Опыт технического аудита, знание архитектурных паттернов	Внутренний курс «Экспертиза ТЗ»
Руководитель	Понимание бюджетного цикла, контроль сроков	Нет
IT-директор	Полномочия по утверждению ИТ-проектов	Указ генерального директора
Администратор	Администрирование Linux, PostgreSQL, Docker	RHCSA или аналог

3. Подготовка к работе

3.1 Состав поставки

В поставку входят:

tehnodoc-tz-module-2.1.0.zip — основной архив;
tz-module-db-2.1.sql — скрипт инициализации БД;
tz-module-docker-compose.yml — шаблон развёртывания;
certs/tz-ca.crt, certs/tz-server.key — TLS-сертификаты (срок действия: до 2026-11-10);
docs/ — каталог документации (включая настоящее Руководство в PDF и HTML).

Контрольные суммы SHA-256:

tehnodoc-tz-module-2.1.0.zip : 7d8e9f0a1b2c3d4e5f6a7b8c9d0e1f2a3b4c5d6e7f8a9b0c1d2e3f4a5b6c7d8
tz-module-db-2.1.sql        : a1b2c3d4e5f6a7b8c9d0e1f2a3b4c5d6e7f8a9b0c1d2e3f4a5b6c7d8e9f0a1b

Проверка:

sha256sum tehnodoc-tz-module-2.1.0.zip

3.2 Установка и развёртывание

Распакуйте архив:

unzip tehnodoc-tz-module-2.1.0.zip -d /opt/tehnodoc/tz

Создайте БД и примените схему:

psql -U postgres -c "CREATE DATABASE tz_module;"
psql -U postgres -c "CREATE USER tz_user WITH PASSWORD 'TzPass2025!';"
psql -U postgres -c "GRANT ALL PRIVILEGES ON DATABASE tz_module TO tz_user;"
psql -U tz_user -d tz_module -f /opt/tehnodoc/tz/tz-module-db-2.1.sql

Настройте окружение:

cp /opt/tehnodoc/tz/conf/.env.example /opt/tehnodoc/tz/conf/.env

Отредактируйте .env:

DB_HOST=localhost
DB_PORT=5432
DB_NAME=tz_module
DB_USER=tz_user
DB_PASSWORD=TzPass2025!
JWT_SECRET=ChangeThisInProduction32Bytes!
SSO_ISSUER=https://sso.example.com/auth/realms/main

Запустите контейнеры:

docker-compose -f /opt/tehnodoc/tz/tz-module-docker-compose.yml up -d

⚠️ Безопасность:
После первого запуска:

смените JWT_SECRET на уникальную строку ≥32 байт;

удалите учётную запись admin@example.com или смените пароль;

настройте ротацию сертификатов (см. Инструкцию по ИБ).

3.3 Проверка работоспособности

Выполните:

curl -k https://localhost:8443/api/tz/v2/health | jq .

Ожидаемый ответ:

{
  "status": "UP",
  "components": {
    "database": { "status": "UP", "details": { "version": "PostgreSQL 14.5" } },
    "auth": { "status": "UP", "details": { "issuer": "https://sso.example.com/..." } }
  },
  "version": "2.1.0",
  "build": "20251110-1422"
}

Также проверьте доступность веб-интерфейса:
https://<host>:8443/tz/ → должна открыться форма входа с логотипом «ТехноДок».

4. Описание операций

4.1 Создание черновика ТЗ

Роль: «Аналитик»

Условия выполнения:

Пользователь аутентифицирован;
Роль «Аналитик» назначена в SSO-профиле;
Нет активного черновика с тем же project_id (блокировка на 24 ч при конфликте).

Подготовительные действия:

Войдите в систему по ссылке https://portal.example.com/tehnodoc.
В главном меню выберите «ТЗ» → «Создать новое».

Основные действия:

Заполните обязательные поля:
- Название ТЗ (не более 255 символов);
- Проект (выберите из выпадающего списка, связь с Jira);
- Инициатор (автозаполняется, редактируется только администратором).
Перейдите на вкладку «Разделы» и заполните структуру по ГОСТ 34.602:
- Раздел 2: «Основание для разработки» — текст + ссылки на регламенты;
- Раздел 3: «Назначение и цели» — цели в формате SMART;
- Раздел 4: «Требования к системе» — используйте шаблоны («Функциональное требование», «Нефункциональное», «Ограничение»).
Нажмите «Сохранить как черновик».

Заключительные действия:

Система присваивает номер TZ-ГГГГ-NNNN (например, TZ-2025-0472);
Черновик появляется в списке «Мои черновики»;
Генерируется уведомление в чат #draft-tz (если подключён Slack-интегратор).

Ресурсы:

Время: 15–45 мин (в зависимости от сложности);
Лимит: до 10 черновиков на пользователя одновременно.

4.2 Согласование ТЗ

Роль: «Руководитель подразделения»

Условия выполнения:

Статус ТЗ: «На согласовании»;
Пользователь назначен согласующим (вручную или по правилу маршрутизации);
До окончания срока согласования (по умолчанию — 3 раб. дня с момента отправки).

Подготовительные действия:

Откройте уведомление в почте или в интерфейсе «Мои согласования»;
Нажмите «Открыть ТЗ».

Основные действия:

Пролистайте ТЗ; используйте панель «Комментарии» для замечаний (поддерживаются @упоминания);
Внизу страницы выберите:
- ✅ «Согласовать» — ТЗ переходит к следующему уровню;
- ✖️ «Вернуть на доработку» — ТЗ возвращается инициатору, статус: «На доработке»;
- ⏸️ «Запросить экспертизу» — добавляется роль «Эксперт», срок согласования приостанавливается.
При возврате укажите причину из справочника: «Некорректная оценка», «Отсутствует раздел 5», «Несоответствие регламенту».

Заключительные действия:

Логируется событие tz.reviewed;
Инициатор получает уведомление с комментарием;
Срок согласования пересчитывается (если возврат — +2 дня на доработку).

5. Аварийные ситуации

5.1 Долгий отказ API (≥5 мин)

Признаки:

HTTP-статус 502/503,
ошибка ERR_CONNECTION_REFUSED в браузере.

Действия пользователя:

Сохраните черновик вручную: Экспорт → Черновик в JSON;
Повторите попытку через 2 мин;
При отсутствии восстановления — уведомите поддержку:
- канал: #sys-support в Slack,
- тема: [TZ] API down: host=prod-tz-01, time=11:42.

Действия администратора:

Проверьте логи:

docker logs tz-app-01 | grep -i "error\|exception" | tail -n 20

Перезапустите сервис:
```
docker restart tz-app-01
```
При повторном отказе — проверьте подключение к БД:
```
SELECT pg_is_in_recovery(), now() - pg_postmaster_start_time() AS uptime;
```

5.2 Ошибка импорта XML (некорректная схема)

Признаки:

Сообщение: «Ошибка валидации XML: cvc-complex-type.2.4.a: Invalid content was found…»;
Код ошибки: XML_VALIDATION_E001.

Действия:

Скачайте отчёт об ошибке: кнопка «Скачать лог валидации»;
Сравните структуру с tz-gost34-2.1.xsd (см. приложение А);
Исправьте:
- обязательные элементы (<section2>, <section3>),
- формат дат (YYYY-MM-DD),
- кодировки (UTF-8, без BOM).
Повторите загрузку.

6. Рекомендации по освоению

6.1 Этапы обучения

Этап	Цель	Продолжительность
1. Наблюдатель	Просмотр ТЗ, комментирование	1 день
2. Исполнитель	Создание черновиков, экспорт	2 дня
3. Согласующий	Работа с маршрутом, возвраты	1 день
4. Администратор	Настройка ролей, мониторинг	3 дня

6.2 Контрольный пример

Сценарий: «Создание ТЗ на разработку модуля отчётов для ELMA365»

Исходные данные (см. приложение Б):

sample-tz-draft.json — черновик в JSON,
suppliers-test.csv — справочник поставщиков.

Последовательность:

Импортируйте черновик: ТЗ → Импорт → JSON;
Добавьте поставщика ИНН 7701234567 из suppliers-test.csv;
Заполните раздел 5: «Состав и структура» — выберите шаблон «Модуль ELMA365»;
Отправьте на согласование (роль «Руководитель» — user:director-test в тестовом окружении);
Выполните согласование;
Экспортируйте результат в PDF.

Критерий успеха:

Полученный файл TZ-TEST-2025.pdf имеет хеш:
sha256sum TZ-TEST-2025.pdf = 9f8e7d6c5b4a3210fedcba9876543210fedcba9876543210fedcba987654321
В логах присутствует запись: event="tz.approved", tz_id="TZ-TEST-2025".

6.3 Тестовые сценарии

📝 Задание 1:
В контрольном примере измените в разделе 4.2 «Сроки разработки» дату окончания на дату, предшествующую дате начала.
Ожидаемый результат: система блокирует сохранение с сообщением «Дата окончания не может быть раньше даты начала».

📝 Задание 2:
Удалите из XML-черновика элемент <section6>. Попытайтесь импортировать.
Ожидаемый результат: ошибка XML_VALIDATION_E003: section6 is required.

📋 Часть 5: Проверочный чек-лист Руководства пользователя

(по ГОСТ Р 59795–2021, п. 6.4)

💡 Рекомендация по использованию:

Разработчик — проходит чек-лист до передачи на редактуру (этап «Написание»),

Редактор/Техлид — применяет при внутреннем рецензировании (этап «Контроль»),

Заказчик/Эксперт ИТБ — использует на приёмке документации (этап «Экспертиза»).

🔹 Этап 1: Проектирование структуры документа

№	Пункт проверки	Стандарт	Как проверить	Комментарий
1.1	В документе присутствуют все шесть обязательных разделов (введение, назначение и условия, подготовка, операции, аварии, освоение)	п. 6.4.1	Проверить наличие заголовков 1–6, их нумерация строго по ГОСТ	Отсутствие хотя бы одного — несоответствие требованиям
1.2	Разделы не переименованы (например, «Инструкция» вместо «Описание операций»)	п. 6.4.1	Сравнить формулировки заголовков с дословным текстом стандарта	Синонимы допускаются только внутри подразделов
1.3	Для модульной АС указано, какая часть системы описывается (например, «Модуль управления ТЗ»)	п. 4.4	Присутствует фраза: «Настоящее Руководство распространяется на…» в разделе 1.1	Без этого — нарушение границы применимости
1.4	Указаны роли пользователей, для которых предназначено РП	п. 6.4.2, п. 5.2.4	В «Введении» и/или «Назначении» есть перечень ролей («Аналитик», «Администратор» и т.д.)	Обобщение вроде «специалисты» — недостаточно

🔹 Этап 2: Наполнение разделов

✅ Раздел 1. Введение

№	Пункт проверки	Стандарт	Как проверить
2.1.1	Указан уровень подготовки пользователя (знания, навыки, допуски)	п. 6.4.2	Есть фраза: «Пользователь должен…» + перечень требований
2.1.2	Приведён перечень сопутствующей документации с обозначениями	п. 6.4.2	Таблица/список: документ — обозначение — назначение
2.1.3	Описание возможностей — без маркетинга, только функциональные заявления	п. 4.2 + здравый смысл	Нет слов «уникальный», «революционный», «лучший»

✅ Раздел 2. Назначение и условия применения

№	Пункт проверки	Стандарт	Как проверить
2.2.1	Для каждой категории условий (техника, ПО, данные, персонал) — конкретные требования, а не общие фразы	п. 6.4.3	Есть: версии ОС/СУБД, форматы данных, роли с компетенциями
2.2.2	Указаны минимум и рекомендовано (если различаются)	п. 6.4.3 + ГОСТ 34.602	Пример: «Минимум: 8 ГБ ОЗУ; Рекомендовано: 16 ГБ»
2.2.3	В требованиях к данным — допустимые форматы и валидация (длина, диапазон, обязательность)	п. 6.4.3	Например: `inn` — 10 или 12 цифр, обязательное поле

✅ Раздел 3. Подготовка к работе

№	Пункт проверки	Стандарт	Как проверить
2.3.1	Указан состав поставки с контролем целостности (контрольные суммы)	п. 6.4.4	Есть SHA-256 для всех бинарных артефактов
2.3.2	Порядок развёртывания — пошаговый, без пропусков (от распаковки до запуска)	п. 6.4.4	Последовательность: 1 → 2 → 3…, с CLI-командами
2.3.3	Указаны действия для проверки работоспособности («smoke-тест»)	п. 6.4.4	Есть: запрос `/health`, вход под тестовым пользователем и т.д.
2.3.4	Учётные данные по умолчанию — только временные, с требованием смены	п. 4.2 + ИБ	Есть предупреждение: «Обязательно смените пароль при первом входе»

✅ Раздел 4. Описание операций

№	Пункт проверки	Стандарт	Как проверить
2.4.1	Каждая операция имеет наименование в повелительном наклонении	п. 6.4.6 (1)	«Создать ТЗ», «Согласовать», «Экспортировать» — не «Форма создания»
2.4.2	Для каждой операции указаны условия выполнения (статус, роль, срок и т.д.)	п. 6.4.6 (2)	Есть: «Статус ТЗ = “На согласовании”, роль = “Руководитель”»
2.4.3	Описана последовательность действий (подготовка → основное → завершение)	п. 6.4.6 (3–5)	Три блока: Подготовительные → Основные → Заключительные
2.4.4	Указаны ресурсы (время, лицензии, лимиты)	п. 6.4.6 (6)	Например: «Требуется 1 лицензия модуля “Согласование”»

✅ Раздел 5. Аварийные ситуации

№	Пункт проверки	Стандарт	Как проверить
2.5.1	Описаны конкретные действия при отказах (не «обратитесь в поддержку»)	п. 6.4.7	Есть: «Перезапустите контейнер: `docker restart tz-app-01`»
2.5.2	Указаны действия при ошибках в данных (импорт, валидация)	п. 6.4.7	Есть: «Скачайте лог валидации → исправьте строку 42 → повторите»
2.5.3	Есть инструкция по несанкционированному доступу	п. 6.4.7	Есть: «Разлогиньтесь, не используйте пароль повторно, уведомите ИБ»

✅ Раздел 6. Рекомендации по освоению

№	Пункт проверки	Стандарт	Как проверить
2.6.1	Есть контрольный пример с исходными данными и критерием успеха	п. 6.4.8	Есть: «Файл `sample-tz.json`, хеш итогового PDF = …»
2.6.2	Приведены тестовые сценарии для самопроверки	п. 6.4.8	Есть: «Задание 1: измените дату → ожидаемая ошибка…»
2.6.3	Описаны этапы обучения по ролям	п. 6.4.8	Есть: «Этап 1 — Наблюдатель (1 день), Этап 2 — Исполнитель (2 дня)…»

🔹 Этап 3: Редактура и оформление

№	Пункт проверки	Стандарт	Как проверить
3.1	Нет внутренней архитектурной информации (API, классы, БД-схемы)	п. 6.4.5	Поиск по ключевым словам: «метод», «таблица», «DTO», «сервис» — их не должно быть
3.2	Все операции связаны с ТЗ (есть трассировка: РП → ТЗ-п.Х.Х)	п. 4.3	В скобках или сносках: (см. ТЗ-ТД-001, п. 7.4)
3.3	Использована единая терминология (сверено с ЕСКД/ГОСТ 34)	ГОСТ Р 2.105	Проверка: «Техническое задание», а не «ТЗ», «спец» или «техзадание» в основном тексте
3.4	Нет учётных данных, паролей, ключей в открытом виде	Базовая ИБ	Поиск: `password`, `secret`, `admin`, `12345` — должны быть заменены на `******` или `<пароль>`

🔹 Этап 4: Финальная экспертиза (приёмка)

№	Критерий приёмки	Допустимо?	Действие при нарушении
4.1	Все требования из ТЗ покрыты операциями в РП	✅ Да / ❌ Нет	Вернуть на доработку с матрицей трассировки
4.2	РП прошёл пилотное тестирование с реальными пользователями (не разработчиками)	✅ Да / ❌ Нет	Запустить пилот (2–3 человека на роль)
4.3	Есть подпись ответственного (техлида, ведущего техписателя) в ведомости документов	✅ Да / ❌ Нет	Добавить в ведомость эксплуатационных документов (п. 5.12)
4.4	Документ согласован с ИБ-службой (если есть требования к защите)	✅ Да / ❌ Нет	Получить акт согласования по форме ПИБ

📎 Приложение: Минимальная матрица соответствия

Для проектов с жёстким аудитом (госзаказ, госкорпорации) рекомендуется прикладывать матрицу соответствия РП требованиям ТЗ и стандарта. Пример фрагмента:

Пункт ТЗ	Наименование функции	Пункт РП	Стандарт (п.)	Статус
7.4.1	Создание черновика ТЗ	4.1	6.4.5, 6.4.6	✅
7.4.2	Многоуровневое согласование	4.2	6.4.5, 6.4.6	✅
7.4.5	Экспорт в PDF/DOCX	4.6	6.4.5	✅
8.2.3	Защита от НСД	5.3	6.4.7	✅
9.1.1	Контрольный пример	6.2	6.4.8	✅

📌 Такая матрица — часть ведомости эксплуатационных документов (п. 5.12) и прикладывается к РП как приложение.

Руководство пользователя​

1. Введение: стандарт и его роль в техническом письме​

1.1. О чём этот стандарт​

1.2. Что такое «Руководство пользователя» в контексте стандарта​

1.3. Структура «Руководства пользователя» по ГОСТ Р 59795–2021 (п. 6.4)​

2. Пошаговое руководство по составлению Руководства пользователя​

Шаг 1. Подготовка и сбор исходных данных​

Шаг 2. Формирование структуры документа​

Шаг 3. Наполнение содержания по разделам​

3.1. Введение​

3.2. Назначение и условия применения (п. 6.4.3)​

3. Подготовка к работе​

3.1. Состав поставки​

3.2. Установка и развёртывание​

3.3. Проверка работоспособности​

3.4. Описание операций (п. 6.4.5–6.4.6)​

Принципы написания:​

3.5. Аварийные ситуации (п. 6.4.7)​

3.6. Рекомендации по освоению (п. 6.4.8)​

Что обязательно включить:​

🚫 Часть 3: Типичные ошибки и методы их предотвращения​

3.1. Ошибка «Технический справочник вместо Руководства»​

Суть:​

Пример нарушения:​

Последствия:​

Причина:​

Как избежать:​

3.2. Ошибка «Недетерминированность условий выполнения»​

Суть:​

Пример:​

Последствия:​

Причина:​

Как избежать:​

3.3. Ошибка «Аварийные ситуации — как приложение, а не как раздел»​

Суть:​

Пример слабого варианта:​

Последствия:​

Причина:​

Как избежать:​

3.4. Ошибка «Контрольный пример — как абстракция»​

Суть:​

Последствия:​

Причина:​

Как избежать:​

3.5. Ошибка «Неадаптированность под роли»​

Суть:​

Пример:​

Последствия:​

Как избежать:​

📘 Руководство пользователя​

Система «ТехноДок»​

1. Введение​

1.1 Область применения​

1.2 Основные возможности модуля​

1.3 Уровень подготовки пользователя​

1.4 Сопутствующая документация​

2. Назначение и условия применения​

2.1 Назначение​

2.2 Требования к техническим средствам​

2.3 Требования к программному обеспечению​

2.4 Требования к входной информации​

2.5 Требования к персоналу​

3. Подготовка к работе​

3.1 Состав поставки​

3.2 Установка и развёртывание​

3.3 Проверка работоспособности​

4. Описание операций​

4.1 Создание черновика ТЗ​

4.2 Согласование ТЗ​

5. Аварийные ситуации​

5.1 Долгий отказ API (≥5 мин)​

5.2 Ошибка импорта XML (некорректная схема)​

6. Рекомендации по освоению​

6.1 Этапы обучения​

6.2 Контрольный пример​

6.3 Тестовые сценарии​

📋 Часть 5: Проверочный чек-лист Руководства пользователя​

🔹 Этап 1: Проектирование структуры документа​

🔹 Этап 2: Наполнение разделов​

✅ Раздел 1. Введение​

Руководство пользователя

1. Введение: стандарт и его роль в техническом письме

1.1. О чём этот стандарт

1.2. Что такое «Руководство пользователя» в контексте стандарта

1.3. Структура «Руководства пользователя» по ГОСТ Р 59795–2021 (п. 6.4)

2. Пошаговое руководство по составлению Руководства пользователя

Шаг 1. Подготовка и сбор исходных данных

Шаг 2. Формирование структуры документа

Шаг 3. Наполнение содержания по разделам

3.1. Введение

3.2. Назначение и условия применения (п. 6.4.3)

3. Подготовка к работе

3.1. Состав поставки

3.2. Установка и развёртывание

3.3. Проверка работоспособности

3.4. Описание операций (п. 6.4.5–6.4.6)

Принципы написания:

3.5. Аварийные ситуации (п. 6.4.7)

3.6. Рекомендации по освоению (п. 6.4.8)

Что обязательно включить:

🚫 Часть 3: Типичные ошибки и методы их предотвращения

3.1. Ошибка «Технический справочник вместо Руководства»

Суть:

Пример нарушения:

Последствия:

Причина:

Как избежать:

3.2. Ошибка «Недетерминированность условий выполнения»

Суть:

Пример:

Последствия:

Причина:

Как избежать:

3.3. Ошибка «Аварийные ситуации — как приложение, а не как раздел»

Суть:

Пример слабого варианта:

Последствия:

Причина:

Как избежать:

3.4. Ошибка «Контрольный пример — как абстракция»

Суть:

Последствия:

Причина:

Как избежать:

3.5. Ошибка «Неадаптированность под роли»

Суть:

Пример:

Последствия:

Как избежать:

📘 Руководство пользователя

Система «ТехноДок»

1. Введение

1.1 Область применения

1.2 Основные возможности модуля

1.3 Уровень подготовки пользователя

1.4 Сопутствующая документация

2. Назначение и условия применения

2.1 Назначение

2.2 Требования к техническим средствам

2.3 Требования к программному обеспечению

2.4 Требования к входной информации

2.5 Требования к персоналу

3. Подготовка к работе

3.1 Состав поставки

3.2 Установка и развёртывание

3.3 Проверка работоспособности

4. Описание операций

4.1 Создание черновика ТЗ

4.2 Согласование ТЗ

5. Аварийные ситуации

5.1 Долгий отказ API (≥5 мин)

5.2 Ошибка импорта XML (некорректная схема)

6. Рекомендации по освоению

6.1 Этапы обучения

6.2 Контрольный пример

6.3 Тестовые сценарии

📋 Часть 5: Проверочный чек-лист Руководства пользователя

🔹 Этап 1: Проектирование структуры документа

🔹 Этап 2: Наполнение разделов

✅ Раздел 1. Введение